home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 621 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.6 KB
  1. Path: chronicle.mti.sgi.com!austern
  2. From: clamage@Eng.Sun.COM (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Some ideas about C++ and a question
  5. Date: 04 Mar 1996 10:30:15 PST
  6. Organization: Sun Microsystems Inc., Mountain View, CA
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4hdctd$r1p@engnews1.Eng.Sun.COM>
  9. References: <4h9smu$m2n@s3.iway.fr>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 4 Mar 1996 00:18:53 GMT
  12. X-Newsreader: NN version 6.5.0 #21 (NOV)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMTs2xky4NqrwXLNJAQGD0gIApc+kD2Gc/FzNOWcGYeHSWKh2HZRLLp96
  15.     VUY1PBXlsX27mHLHWQ6AFcTegyf7kssQCG/qwTyAyE7x5jkUTo+l1A==
  16.     =gydT
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Valentin Bonnard <bonnardv@pratique.fr> writes:
  20.  
  21. >I have 4 ideas about C++ and a question.
  22.  
  23. >1) String literals
  24. >~~~~~~~~~~~~~~~~~~
  25. >String literals should be const char* instead of char* (if it is not
  26. >already the case).
  27.  
  28. Yes, it is clearly the "right" thing to do, but it is not the case
  29. for the same reason it is not the case in Standard C: it would break
  30. too much existing code to make the change.
  31.  
  32.  
  33. >2) Placement operators
  34. >~~~~~~~~~~~~~~~~~~~~~~
  35. >class Object {
  36. >        void    operator+ // or / or whatever
  37. >                         (Object& result, const Object& b) const;
  38. >        void    operator* (Object& result) const;    #2
  39. >        Object  operator* (const Object& result) const; // old one
  40. >}
  41.  
  42. >should be called respectively by:
  43. >a = b + c;
  44.  
  45. >and a = *b;
  46.  
  47. >and (old one) a*b;
  48.  
  49. >This will solve the [well-known] problem of copying the result into a temporary.
  50. >The compatibility will be preserved since old syntax will be allowed to.
  51.  
  52. You will have to present this idea in more detail. I can't figure out
  53. what you are proposing. It looks like you want the function marked #2
  54. to be some form of unary dereferencing operator, but that would change
  55. its existing meaning of a member binary (multiplication) operator.
  56.  
  57. >3) Use of explicit keyword
  58. >~~~~~~~~~~~~~~~~~~~~~~~~~~
  59.  
  60. >void    foo (explicit Derived* object) ...
  61.  
  62. Evidently you want this to mean that "*object" is of type "Derived"
  63. and not of any type derived from "Derived". I guess I don't see
  64. the utility of the declaration. You can create a type which cannot be
  65. derived from, if that is what you want. If you don't want that, I
  66. don't see why the author of "foo" wants to be sure no derived type
  67. is ever passed to it. What programming problem is being solved here?
  68.  
  69. The whole idea of public derivation is that a derived type can be
  70. used where ever a base type is expected. Why does the author of foo
  71. want to ensure that the actual object has, for example, no additional
  72. data, functionality, or instrumentation, when the author of Derived
  73. has no objections to the possibility?
  74.  
  75. If for some reason you do care about the actual type of *object,
  76. wouldn't it be enough to use an RTTI expression in the function?
  77.  
  78.  
  79. >4) Conversion of Type** to const Type**
  80. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  81.  
  82. >It's ok, this is an error; but why cannot Type** be converted to const Type* 
  83. >const* ?
  84.  
  85. For the same reason: it could cause a violation of constness without
  86. a cast. The draft standard does allow Type** to be converted to
  87. "Type*const*", since that cannot cause any such violation.
  88.  
  89.  
  90. >Now a question:
  91.  
  92. >Will there be any way to redefine (overload) normal && or || on class ?
  93. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  94.  
  95. > ...
  96.  
  97. >One could think that the standard should be change in order to support real
  98. >overloaded operator && and ||.
  99.  
  100. If by "real" overloading you mean adopting the short-circuit evaluation
  101. rules, I don't think that will (or should) happen.
  102.  
  103. When you write 
  104.     I || Func()
  105. it is just another way to write
  106.     I.operator||( Func() )
  107.  
  108. Let's simplify things by considering
  109.     A || B // A's type has an operator||
  110. which is the same as
  111.     A.operator||( B )
  112.  
  113. Suppose the type of A did not have any conversion to bool. You could
  114. not evaluate the "truth" of A, and so you would have to call the
  115. function "||" after evaluating B, no matter what the value of A.
  116. In other words, short-circuit evaluation would not be a possibility.
  117. But if A could be converted to bool, the same expression with the
  118. same value of A could result in short-circuit evaluation (don't
  119. evaluate B and don't call "||"). That sounds like a poor idea to me.
  120. Others might disagree.
  121. --
  122. Steve Clamage, stephen.clamage@eng.sun.com
  123. ---
  124. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  125.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  126.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  127.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  128.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  129. ]
  130.